Decompiler in C# with source for MOHAA

**Ley0k** · July 15th, 2018, 05:54 AM

Static models don't require too much work :


struct BSP::File_StaticModel
{
	char model[128];
	vec3_t origin;
	vec3_t angles;
	float scale;
	int32_t firstVertexData;
	int32_t numVertexData;
};

void BSP::LoadStaticModelDefs(const GameLump* GameLump)
{
	if (!GameLump->Length)
	{
		return;
	}

	if (GameLump->Length % sizeof(File_StaticModel))
	{
		return;
	}

	size_t NumStaticModels = GameLump->Length / sizeof(File_StaticModel);
	if (NumStaticModels > 0)
	{
		staticModels.resize(NumStaticModels);

		const File_StaticModel* In = (File_StaticModel *)GameLump->Buffer;
		StaticModel* Out = staticModels.data();

		for (size_t i = 0; i < NumStaticModels; In++, Out++, i++)
		{
			Out->visCount = 0;
			Out->angles = In->angles;
			Out->origin = In->origin;
			Out->scale = In->scale;
			Out->firstVertexData = In->firstVertexData;
			Out->numVertexData = In->numVertexData;
			Out->modelName = CanonicalModelName(In->model);
		}
	}
}

Once you got them, just generate them as if they were entities

**chrissstrahl** · July 15th, 2018, 06:21 AM

I got feedback from will:

Just made a few commits which should solve a few issues:
m3l2 should decompile now.
Translucent and sky textures shouldn't be getting replaced anymore.
Detail brushes should be properly marked now.

Let me know how things look. I've filed issues in the GitHub repo for the terrain and static models as well, hopefully I can knock those out soon.

I will send him a mail with your feedback in it.

**1337Smithy** · July 16th, 2018, 01:03 PM

This gave me an excuse to download Visual Studio again so I could look at his work and generate the executable. Not used it since uni...

So far it's looking much better. Transparent textures are looking good. I can decompile the problematic map now. Detail brushes persist.

I'll keep looking for bugs!

**chrissstrahl** · July 16th, 2018, 04:14 PM

Sounds great.

From the notes on git there have been quite some improvments based on the feedback from this forum here.

I think terrain and static models are still a issue.

Is there a list for the static models or something how do we know which is which or where to read the data from the bsp in the right way ?
This is what he wrote me back earlier. (Note: I have edited this quote a little )

I've looked into static models a bit more and... they actually made a new entity class for every static model in the game.
The model is stored in the BSP but the entity classname is not! So it looks like I'd have to made a list of every model and map them to the proper entity.
The best way to figure this out is to have a .map created in the editor that has one of every type of static model entity in it, but there's hundreds of them.
I'm starting to see why the other decompiler doesn't support them...

**1337Smithy** · July 17th, 2018, 05:09 AM

http://www.mediafire.com/file/t734qg...est_models.map

**Ley0k** · July 17th, 2018, 06:11 AM

Originally Posted by chrissstrahl

Is there a list for the static models or something how do we know which is which or where to read the data from the bsp in the right way ?

The lump for static models is the 25th, and the struct for for an element is :


struct
{
	char model[128];
	vec3_t origin;
	vec3_t angles;
	float scale;
	int32_t firstVertexData;
	int32_t numVertexData;
};

Just read it as you do with shaders, brushes, surfaces, etc... Static models aren't entities, they were implemented to avoid filling entities list with static models, and also to optimize rendering.
You can convert this data into an entity for map files :


{
"classname" "quaked_tiki_class"
"scale" "scale"
"model" "model"
"origin" "x y z"
}

**1337Smithy** · July 17th, 2018, 06:48 AM

Hmm, so static entities won’t make me hit the entity limits in a map?

**chrissstrahl** · July 17th, 2018, 08:26 AM

Hmm, so static entities won’t make me hit the entity limits in a map?

Um, there are two limits, one that is the active entity limit that usually is 1024 but can be changed saftly to 2048 (as far as I can tell)
and there is the actual overall map source-file entity limit, which should be arround 4096 to my knowlage (Includes also light/static entities).

Yes, these should not affect the active entity limit in the game.
How ever, they matter with that map-file source limit of 4096, at some point you can't compile the map (or even load it in the editor anymore).

**MofoMan2000** · July 17th, 2018, 08:53 AM

Ahoy there. So I was pointed to these forums by mister Chris here and thought I'd chime in.

The issue with static models that I'm having is not that the format is hard to read or anything, it's pretty straightforward. It's that, in the editor, regardless of how they are used in the engine, they are each given unique entity classes. For example, here's two static model entities from the m4l0.map included with MoHTools.

// entity 1526
{
"testanim" "idle"
"angle" "180"
"origin" "4944.00 2214.00 536.00"
"model" "miscobj//hidden_cabinet_b.tik"
"scale" "1.0"
"classname" "static_furniture_hidden-cabinet-dark"
}
// entity 1527
{
"origin" "-780.00 7216.00 176.00"
"testanim" "idle"
"model" "static//woodbucket.tik"
"scale" "1.0"
"classname" "static_item_woodbucket"
}

Their classnames are unique to each model, and there's no way to pull them directly from the BSP file itself.

Now, it could be that these are irrelevant, and I could stick them all into "static_item_woodbucket" entities and it would be fine. I honestly don't know.

And regarding another piece of feedback passed on to me from here:

VIS comes back as a world brush instead of a leafgroup.

I don't have much experience with mapping for MoHAA so I'm not quite sure how these entities work. But looking at m4l0 again, I'm not sure there's any way I could recreate them. They just come out of the BSP as world brushes. The data for them might be hidden away somewhere in another lump, I don't know. If anyone has any insight on these I'd really appreciate it!

**1337Smithy** · July 17th, 2018, 09:39 AM

Originally Posted by chrissstrahl

Um, there are two limits, one that is the active entity limit that usually is 1024 but can be changed saftly to 2048 (as far as I can tell)
and there is the actual overall map source-file entity limit, which should be arround 4096 to my knowlage (Includes also light/static entities).

Yes, these should not affect the active entity limit in the game.
How ever, they matter with that map-file source limit of 4096, at some point you can't compile the map (or even load it in the editor anymore).

Yeah, I guess these are the standard Quake 3 limits? Not sure if it was changed at all with this modified engine, though I seem to remember even Source has similar or same values, at least with brush and face count. I think the first limit is more important (I've always assumed this means those that are rendered inside the player's PVS at any given time) as I find it difficult reaching the overall entity limit. My last map only had half that and it was pretty heavy with static models.

Originally Posted by MofoMan2000

Ahoy there. So I was pointed to these forums by mister Chris here and thought I'd chime in.

The issue with static models that I'm having is not that the format is hard to read or anything, it's pretty straightforward. It's that, in the editor, regardless of how they are used in the engine, they are each given unique entity classes. For example, here's two static model entities from the m4l0.map included with MoHTools.

Their classnames are unique to each model, and there's no way to pull them directly from the BSP file itself.

Now, it could be that these are irrelevant, and I could stick them all into "static_item_woodbucket" entities and it would be fine. I honestly don't know.

And regarding another piece of feedback passed on to me from here:

I don't have much experience with mapping for MoHAA so I'm not quite sure how these entities work. But looking at m4l0 again, I'm not sure there's any way I could recreate them. They just come out of the BSP as world brushes. The data for them might be hidden away somewhere in another lump, I don't know. If anyone has any insight on these I'd really appreciate it!

I never thought the classname was hugely important personally (though it may cause errors in the log if not right). Inside the .tik often a classname isn't even specified, and it simply defaults to the quaked name (though these may be two separate things). E.g. with:


TIKI
setup
{
	scale 0.52			// Set default scale to 16/30.5 since world is in 16 units per foot and model is in cm's
	//scale 1.33			// Convert from inches to game units
	path models/static/barbwire
	skelmodel barbwire_post.skd
	surface bwirepost shader static_bwirepost
}

animations
{
	idle    barbwire_post.skc
}

/*QUAKED static_obstacle_barbwire-post (0.5 0.0 0.5) (0 0 0) (0 0 0)
*/

The classname becomes static_obstacle_barbwire-post.

I assume that is why Ley0k's code is the way it is. Anyway, one of the other guys will need to provide an answer as they have experience in this stuff, and not to mention, they've seen behind the curtain as it were lol.

Oh, and I wouldn't worry much about the VIS objects. It was just an observation. If it isn't fixable then I wouldn't worry.

Thread: Decompiler in C# with source for MOHAA

Thread Tools

Display

Posting Permissions